

X-542-65-445 


GPO PRICE $. 
CFSTI PRICE(S) $ 


K= & y ''M \ ■ 


i iV 


533 // 


. N66 37813 


(ACCESSION NUMBER! 


ION NUMBER 

/■f 


/ 


! ! -&m-- 



(NASA CR OR TMX OR AD NUMBER) 


3/ 

(CATEGORY! 


> . : . , BY ; ■ „ 

WILLIAM D. CARPENTER 


Hard copy (HC) /• 
Microfiche (MF) , 

11653 July 66 


OCTOBER 1965 



GODDARD SPACE FLIGHT CENTER 

GREENBELT, MARYLAND 


X-542-65-445 


THE TASK MANAGER 


William D. Carpenter 


October 1965 


Advanced Orbital Programming Branch 
Data Systems Division 


Goddard Space Flight Center 
Greenbelt, Maryland 


1 


* 


f 


FOREWORD 

The following article was written as; an aid to the programmer 
turned task manager. The principles developed, while expressed in 
the jargon of programming, are general enough to be applicable to 
other disciplines. 
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THE TASK MANAGER 
by 

William D. Carpenter 


"Management has been defined as the science of establishing proper objectives 
and efficiently utilizing human, material, and time resources to achieve the ob- 
jectives." The real crux of this statement is "proper objectives". Without proper 
objectives, no plan, no matter how carefully executed, will succeed in delivering 
the goods. So, we ask ourselves, "How do we achieve a proper objective?" The 
easiest way, of course, is to set up objectives based on a set of details furnished 
by a sponsor. Experience has shown that we will wait a long time for such de- 
tail with the result that our contribution in the programming field will be rendered 
impotent and subject to criticism. The only way to guard against this potential 
black-eye is to seize the initiative and come up with a set of specifications which 
satisfy the problem sponsor and with which we can live. As applied to AOPB, it 
seems only reasonable that this kind of work should be performed by one man, 
acting as a single point of contact between the branch and the sponsor, to guaran- 
tee a continuity of effort and to avoid costly and needless duplication. Such a 
person we call a task manager. 

Where does a task manager come from? How do we recognize him? 

Well, he is usually bom. He spends his childhood on the usual carefree dis- 
tractions; in adolescence he chases girls; and, in early manhood he acquires an 
education and chases girls. After graduation he obtains that most sought after of 
jobs, programmer. 

Then one day a swivel hipped computer catches his eye. She teases him with 
flashing lights and whirling tapes; she lures him on with a never ending promise 
of bigger and better ways to do things. She flatters him with, "If you want it done 
right, do it yourself . 

One day our young man gets a big job which is really worthy of his talents. 
After all, has he not learned the computer's every caprice and mastered every 
technique of the progra mm er's art? He attacks it with gusto, only to find out 
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that he knows how to do the job, but simply does not have the time. He asks for 
people to help him. But this alone does not seem enough. He realizes that he 
needs something more than people; he needs the ability to get these people to do 
the job as well as he himself could do it if only he had the time - a potential task 
manager is born. 

Let us examine the way a job comes to the branch. A telephone request is 
usually made to the branch head requesting assistance in support of a project. 

This phone call details little more than the name of the project, its sponsor and 
the rather vague request to "let the computer do it". Based on such sketchy in- 
formation, no commitment can be made to undertake the job. Consequently, 
someone is dispatched to the sponsor to learn more details about the problem. 
From this meeting there emerges sufficient information to allow the branch head 
to make some gross estimates about the job: What kind of job is it? How large 
is it? What is its due date and what are the areas of responsibility? There is 
still little information which would allow the intelligent use of a programmer’s 
time. The thing missing, of course, is the detailed information needed to write 
the program (or system). Assuming the project has branch and division approval, 
a task manager is assigned to discharge the obligations of the branch for the 
project. 

The task managers job now begins in earnest. He assumes full responsibility 
for getting the job done. He sees to it that an abstract is written. He acts as 
liaison with the problem sponsor at all times so that he may direct the planning, 
scheduling, and reporting of all phases of the project and supervise members of 
the task group. 

It is assumed that the task manager has the requisite technical skills. It 
remains to be defined how the task manager will go about his managerial duties 
of establishing and maintaining "proper objectives". Planning, scheduling, and 
reporting are the rudimentary tools which help him to do this. Let us examine 
each of these tools. 

All projects, regardless of size, should have a written plan covering what is 
going to be done, how, when, and by whom; and what the foreseeable problems 
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may be and how they will be overcome. The task manager usually has such a 
plan in mind, at least informally, during all phases of the operations. The docu- 
mented plan is not so much for the task manager's own use as it is a means of 
communicating with the project people and with members of the task group. Its 
initial breakdown sets the stage for all subsequent planning. It must be done 
carefully to reflect the proper level of sub- tasks without becoming a mere paper 
exercise. It should go only so deep as to reflect the slippage expected in the 
schedule caused by fluctuations in project requirements as work progresses. 

This will avoid misunderstandings toward the end of the project if the work is 
not deliverable on the date originally set. 

Programming, for example, should be broken up into its component parts of 
system description, flow charts, coding, and check-out to reflect where the real 
delay lies instead of allowing the project people to point an accusing finger at 
that ol' devil, programming. While on the subject of depth of planning, experience 
has shown that the following breakdown into major milestones is helpful: 

1. Abstract - This is prepared by a task manager or senior programmer 
based on initial discussions with the project manager. It contains a brief state- 
ment about the nature of the problem and its magnitude; it defines areas of re- 
sponsibilities and interfaces, and lists due dates. The abstract allows the branch 
chief and the division office to assess our capability to undertake the job. 

2. System Analysis and Design - This is performed by the task manager or 
senior programmer. It defines "what” the job is, "how" it is to be solved (both 
from hardware and software points of view), and outlines any foreseeable problem 
areas together with any suggested courses of action. The analysis should contain 

a title and brief description for each task and sub-task as an aid to communication. 

3. System Description - This is prepared by a senior programmer and is 
the implementation of the system analysis and design to produce detailed specifi- 
cations, right down to the level of describing the I/O, operating notes and all 
interfaces. 

4. Flow Charting - This is prepared by a senior programmer. It is a 
schematic of the system description. 
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5. Coding - This is performed by a group of junior programmers and pro- j 
duces the software package which delivers the goods. 

6. Check-out - This phase is performed by senior and junior programmers.; 
It checks out step 3 to see if what was specified was actually programmed. 

7. Simulation - This function is performed by the task manager and senior 

programmers. It is a certification of step 2, meaning it checks the system to 
see that it does the job requested by the project manager. ' 

8. Documentation - This function is performed by a technical writer, usual! 
by contract under the direction of the task manager. 

When all milestones have been completed the system is ready to be turned 
over to an operational group. The task manager's job is complete. 

It will be noted that the above milestones reflect two kinds of planning: top- 
down planning represented by the abstract and bottom-up planning represented 
by Systems Analysis and Design. The first, or top-down planning, is more likely 
be influenced by the authority and responsibilities of functional management tha 
by the needs and requirements of the project. Management says, "Do this or 
that." or "Here are the project goals and requirements. Put them on the com- 
puter." Bottom-up planning on the other hand determines if it is possible to 
actually do this or that; it decides if it is feasible within the constraints of hare 
ware and software. Bottom-up planning sees to it that jobs essential to the 
project get done and foresee any stumbling blocks that may prevent this. 

In order for this two-way planning to work most effectively the task manag 
must be a real contributor to the plan as well as a contributor to the actual 
work; in short, he makes things happen. He must clearly portray the objective 
of the project to team members; he must communicate fully and clearly with 
project management. A constant awareness of the end product, combined with 
clearly defined and clearly assigned task and sub- task objectives are the prim 
keys to tapping the full potential of the project team. 

In the area of research and development associated with project work, 
changes in depth and scope of planning are inevitable. Therefore, the task ! 
manager will find it necessary to review and update plans frequently and to 


build a flexible plan. A flexible scheduling and reporting system has been de- 
signed to implement this. It is intended to be concise and easy to fill out; it 
should give the task manager and the branch chief a quick evaluation of the status 
of the project, should pinpoint trouble spots early, and should form a pool of 
information from which a timely report may be written to satisfy every request 
made by the division office and by the project management. 

The instruments recommended for scheduling and reporting are: 

1 & 2. The Abstract and System Analysis and Design, previously described. 

3. The Task Schedule should list at a minimum the major milestones 
mentioned earlier for each task and sub- task included in the System Analysis. 
Other tasks may be listed; however, discretion should be used to avoid trivia 
which would tend to obscure the purpose of the schedule. 

4. Machine Time Budget reflects the amount and schedule of machine 
time necessary to support the effort. 

5. The Task Report should be submitted for every item on the schedule. 
These should be filled out by the person working on the particular item with the 
approval of the task manager. The task manager should supply a similar report 
which reflects the status of the overall project with particular attention being 
paid to potential trouble spots. 

It is absolutely necessary for a viable reporting system that the task m a n ager 
be on time with his own reports and those of his task group. This is so important 
in fact, that all work should be suspended on the project until the milestone reports 
are completed. Under no circumstances should a report be delayed, even for so 
much as a single day, in hopes of reporting an additional accomplishment. Let 
it wait for the next period. The task manager should keep a log of milestone 
dates so that he requires no dunning from the branch chief for a tardy report. 

It is hoped that this paper has cast some light ori the "proper objectives" of 
management. The material and time resources mentioned in our definition are 
largely dictated by the magnitude of the job and its competition with other jobs 
at the Center. Contract support in terms of both computer time and programmer 
time are an un-tapped resource at the disposal of the task manager. 
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The area of utilization of humans was omitted from the discussion as being yk 
outside the scope of this paper. A few words, however, are in order. The task 
manager should take the true measure of his team members in estimating the 
group’s ability to do a job. A pie- in- the- sky approach which rates all persons 
at the top of the spectrum of competence holds only surprises and disappointments 
for the task manager. The field of group leadership offers a new challenge to 
the task manager which, if he masters it, will extend his ability to handle larger 
jobs and will lead him to say, "If you want it done right, get others to do it". 

BIBLIOGRAPHY 

Baumgartner, JohnS., "Project Management", R. D. Irwin, Inc. 

Karger, Delmar W. and Murdick, Robert G., "Managing Engineering and Research", 
The Industrial Press. 

Roman, Daniel D., "Project Management Recognizes R&D Performance", Academy 
of Management Journal, V. 7-1 Mar. '64. 

Odiorne, G. S., "How Managers Make Things Happen", Prentice-Hall, Inc. Engle- 
wood Cliffs, N. J., 1961. 
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